Connected payment card systems and methods

ABSTRACT

Methods and systems of managing payment cards are disclosed. A financial institution computing system includes a token database storing a plurality of tokens and token information, a network interface circuit enabling the financial institution computing system to exchange information over a network; and a token management circuit. The token management circuit enables a graphical user interface on a customer device over the network that can be used to generate new token requests, re-provision token requests, and management requests. The management requests enable and disable tokens, such that transactions against a payment card account using an enabled token are completed, and transactions against the payment card account using a disabled token are denied.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.15/054,633, filed Feb. 26, 2016, which claims the benefit of priority toU.S. Patent Application No. 62/199,783, filed Jul. 31, 2015, both ofwhich are hereby incorporated by reference in their respectiveentireties.

BACKGROUND

Payment cards can be provided in many forms beyond a plastic card with amagstripe. Payment cards can be provided with on-board integratedcircuits and can be provisioned to mobile devices for mobile wallettransactions. Such arrangements can be used for both in-person andon-line transactions. However, while payment cards reduce the need tocarry physical currency, payment card transactions can entail securityrisks. Further, many existing systems manage security issues on anaccount-by-account basis. As such, a customer may have to freeze orclose an entire payment card account as a result of a security breach ata single merchant. Resorting to an account-wide freeze can besignificantly disruptive, particularly where the customer has a limitednumber of available payment source accounts.

SUMMARY

One example embodiment relates to a financial institution computingsystem. The system includes a token database, a network interfacecircuit, and a token management circuit. The token database retrievablystores a plurality of tokens and token information associated with eachof the plurality of tokens. The network interface circuit enables thefinancial institution computing system to exchange information over anetwork. The token management circuit is configured to enable agraphical user interface on a customer device over the network. Thetoken management circuit is further configured to cause a new token tobe provisioned in response to a new token command generated by thegraphical user interface. The token management circuit is configured tocause a token to be re-provisioned in response to a re-provision tokencommand generated by the graphical user interface. The token managementcircuit is further configured to enable and disable tokens in the tokendatabase in response to management commands generated by the graphicaluser interface. Transactions against a customer payment card accountusing an enabled token are completed, and transactions against thecustomer payment card account using a disabled token are denied.

Another example embodiment relates to a method of enabling real timepayment card account management for customers of a financialinstitution, including management of physical payment cards, asperformed by one or more circuits at a financial institution computingsystem. The method includes retrievably storing, by a token database, aplurality of tokens and token information associated with each of theplurality of tokens. The method further includes enabling, by a networkinterface circuit, the financial institution computing system toexchange information over a network. The method includes enabling, by atoken management circuit, a graphical user interface on a customerdevice over the network. The method further includes responding, by thetoken management circuit, to requests provided by the graphical userinterface, including causing a new token to be provisioned in responseto a new token request, causing a token to be re-provisioned in responseto a re-provision token request, and enabling and disabling tokens inthe token database in response to management requests. A transactionagainst a customer payment card account using an enabled token iscompleted, and wherein a transaction against the customer payment cardaccount using a disabled token is denied.

Yet another arrangement relates to a non-transitory computer readablemedia having computer-executable instructions embodied therein that,when executed by a processor of a financial institution computingsystem, cause the financial institution computing system to performoperations to enable real time payment card account management forcustomers of a financial institution, including management of physicalpayment cards. The operations include retrievably storing, by a tokendatabase, a plurality of tokens and token information associated witheach of the plurality of tokens. The operations further includeenabling, by a network interface circuit, the financial institutioncomputing system to exchange information over a network. The operationsinclude enabling, by a token management circuit, a graphical userinterface on a customer device over the network. The operations furtherinclude responding, by the token management circuit, to requestsprovided by the graphical user interface, including causing a new tokento be provisioned in response to a new token request, causing a token tobe re-provisioned in response to a re-provision token request, andenabling and disabling tokens in the token database in response tomanagement requests. A transaction against a customer payment cardaccount using an enabled token is completed, and wherein a transactionagainst the customer payment card account using a disabled token isdenied.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram illustrating a payment card and tokenprovisioning system, according to an example embodiment.

FIG. 2 is a block diagram illustrating additional features of thepayment card and token provisioning system shown in FIG. 1.

FIGS. 3A-3D are depictions of various screens generated on a userinterface, which may be used to facilitate a payment transaction,according to example embodiments.

FIG. 4 is a flowchart of a method of provisioning a payment card,according to an example embodiment.

DETAILED DESCRIPTION

Referring to FIG. 1, a payment processing system 100 includes afinancial institution computing system 102, a customer device 104, amerchant computing system 106, and a card network computing system 108.A network 110 enables components of the system 100 to communicate witheach other. The network 110 is a data exchange medium, which may includewireless networks (e.g., cellular networks, Bluetooth®, WiFi, Zigbee®,etc.), wired networks (e.g., Ethernet, DSL, cable, fiber-based, etc.),or a combination thereof. In some arrangements, the network 110 includesthe internet.

In example embodiments, payment processing system 100 uses paymenttokens to facilitate payments to merchants. In example embodiments,payment tokens may be surrogate values that replace the primary accountnumber (PAN) associated with a payment card, such as a credit card,debit card, stored value card, etc. Payment tokens may pass basicvalidation rules of an account number. Hence, the payment token for acredit card in many respects “looks like” a real credit card number, butin fact is only a token. As part of the token generation process, stepsare taken such that the generated payment token does not have the samevalue as or conflict with a real primary account number (e.g., a realcredit card number). Payment tokens may be provisioned to variouslocations for use in various types of payment scenarios, includingremote storage at a merchant (e.g., a card-on-file database) for on-linetransactions with the merchant, a secure storage element (“secureelement”) located in a payment card for a point-of-sale transactionusing the payment card, local device storage (e.g., internal memory of amobile device) for a mobile/digital wallet transaction, and so on.

In example embodiments, to process payment transactions, a payment isprocessed using a payment token in lieu of a primary account number(e.g., the 16-digit account number on the front of a credit card). Themerchant obtains the payment token from a customer device or from thepayment card, and then submits the payment token through a paymentnetwork to a computing system associated with a card network (e.g.,Visa®, MasterCard®, American Express®, Discover®, Diners Club®, etc.).The card network computing system detokenizes the payment token toobtain the PAN, i.e., replaces the payment token for its associated PANvalue based on the payment token-to-PAN mapping information stored in atoken database (sometimes referred as a “token vault”). The card networkcomputing system then transmits the PAN to the card issuer (e.g., thecustomer's financial institution) for processing in a manner similar toa traditional credit card transaction. For example, the card issuer mayapprove the transaction, in which case the transaction with the merchantis completed and payment to the merchant is made. The token database mayalso maintain other information that may be used to apply restrictionsor other controls during transaction processing.

In example embodiments, processing payment transactions using suchpayment tokens provides enhanced security in connection with the paymentcard transactions. The payment tokens may be limited to use, e.g., onlyin connection with a specific merchant or a specific channel (e.g.,payment via a specific mobile wallet). For example, in the event of adata breach at a merchant, the risk of subsequent fraud is reducedbecause only the payment tokens are exposed instead of primary accountnumbers. In this example, the payment tokens are merchant-specific andtherefore cannot be used at other merchants. Although the examplesprovided herein relate primarily to the use of payment tokens (which maybe used to originate payment transactions), the systems and methodsdescribed herein may also be used with and non-payment tokens (which maybe used for ancillary processes, such as loyalty tracking), as describedin greater detail below.

Referring again in detail to FIG. 1, the financial institution computingsystem 102 is a computing system at a financial institution that iscapable of maintaining customer accounts (e.g., payment card accounts,such as credit card accounts, demand deposit accounts having anassociated debit card, stored value card accounts, and so on) anddatabases of customer information. In the context of the presentdisclosure, the financial institution can include commercial or privatebanks, credit unions, investment brokerages, and so on.

The customer device 104 is a computing system associated with a customerof the financial institution. The customer device 104 includes one ormore processors and non-transitory storage mediums housing one or morelogics configured to allow the customer device 104 to exchange data overthe network 110, execute software applications, access websites,generate graphical user interfaces, and perform other operations.Examples of the customer device 104 include laptop computers, desktopcomputers, mobile devices (tablets, smartphones, wearable computingdevices such as eyewear, etc.), and so on.

The merchant computing system 106 is a computing system associated witha merchant with which a customer of the financial institution maytransact. Examples of merchants include, for example, retailers,wholesalers, marketplace operators, service providers (e.g., loanservicers, cleaning services, transportation providers, digital walletservices, and so on), and so on. In some arrangements, the merchantcomputing system 106 is used to create and store data relating tocustomer transactions (e.g., purchases and refunds). In some sucharrangements, the merchant computing system 106 can store databases ofinformation relating to customers such as names, shipping addresses,contact information, and so on. Further, the merchant computing system106 may be able to operate customer loyalty programs (e.g., membershipprograms, points programs, frequent shopper discounts, and so on).

The card network computing system 108 is a computing system associatedwith a card network. Examples of card networks include Visa®,MasterCard®, American Express®, Discover®, Diners Club®, etc. In someembodiments, the card network computing system 108 generates tokens forpayment cards. The card network computing system 108 performs operationsassociated with the generation and issuance of payment tokens. The cardnetwork computing system 108 also maintains the established mapping ofpayment tokens-to-PANs in a token database (or token vault). The cardnetwork computing system 108 also detokenizes payment tokens duringprocessing of payment transactions to determine actual account numbers.

Referring now to FIG. 2, system 100 is shown in greater detail accordingto one example embodiment. In FIG. 2, the financial institutioncomputing system 102 includes a FI customer database 202, a tokendatabase 204, a token management circuit 206, a data exchange circuit208, and an FI network interface circuit 210. The FI network interfacecircuit 210 is configured to allow the financial institution computingsystem 102 and the various components therein to exchange data over thenetwork 110.

The FI customer database 202 allows the financial institution computingsystem 102 to retrievably store customer information relating to thevarious operations discussed herein, and may include non-transient datastorage mediums (e.g., hard drives, local network servers, and the like)or remote data storage facilities (e.g., cloud servers). The FI customerdatabase 202 includes personal customer information (e.g., names,addresses, phone numbers, and so on), identification information (e.g.,social security numbers, driver's license numbers, biometric data, andso on), customer financial information (e.g., account numbers, accountbalances, available credit, credit history, transaction histories,etc.), and so on.

The token database 204 is a storage medium which may be similar to theFI customer database 202, except that the token database 204 storestoken information. The token database 204 may be a token vault that ismaintained by the FI computing system 102. Hence, in some embodiments,the payment tokens are generated by the card network computing system108, and payment token-to-PAN mapping information is maintained by thecard network computing system 108; and, in addition, the paymenttoken-to-PAN mapping information is also maintained by the FI computingsystem 102. For example, in some embodiments, the FI computing system102 may provide additional token-related management services tocustomers that are not available through the card network computingsystem 108. Such services may be useful in situations where customershave multiple different types of accounts, e.g., multiple differenttypes of credit cards, such that a single card network computing systemdoes not have a global view of all of the payment tokens in existencefor a given customer. Such services may also be useful in situations inwhich information in addition to account numbers is tokenized by FIcomputing system 102 (or other computing systems), thereby creatingtokens that are not payment tokens.

To this end, in some embodiments, the token management circuit 206 isconfigured to enable such services. The services may be provided both inconnection with non-payment tokens and in connection with paymenttokens. Regarding non-payment tokens, in one aspect, the tokenmanagement circuit 206 can generate a new unique code to be provisionedas a token, and associate a discrete piece of data with the new uniquecode (e.g., information other than a payment card number). The newunique code then becomes a token, which may be exchanged among computingdevices.

In another aspect, with regard to payment tokens, the token managementcircuit 206 may be configured to cooperate with card network computingsystem 108 to activate and deactivate individual payment tokens. Inother words, the token management circuit 206 may be configured toprovide token-related management services to customers to activate anddeactivate individual payment tokens or to otherwise configurepermissions associated with such tokens. For example, a customer openinga new credit card account may be assigned a primary account number (PAN)specifically identifying that new account (e.g., a sixteen-digit creditcard account number) by the FI computing system 102 and/or by the cardnetwork computing system 108. The customer may engage in transactionswith one or more merchants, each of which may be assigned a paymenttoken specific to each merchant or to a specific payment channel (e.g.,a specific brand of mobile wallet). The card network computing system108 may generate each of the payment tokens and provide informationabout the payment tokens to the FI computing system 102. The tokenmanagement circuit 206 may be configured to cooperate with card networkcomputing system 108 to maintain the payment tokens over their lifecyclein the databases 204 and 228.

In some embodiments, the token management circuit 206 provides a tokenmanagement hub tool accessible via the customer device 104. The tokenmanagement hub may be provided as a graphical user interface andpresented to a customer via the customer device 104. The customer canaccess the management hub through via an online banking website, via amobile banking tool provided to a mobile device, and/or in anothermanner. The customer may be required to provide login credentials (e.g.,username and password, biometrics, etc.). Upon authenticating thecustomer, the data exchange circuit 208 may transmit account informationfor that customer from the FI customer database 202 and/or the tokendatabase 204 to the customer device 104 to provide the token managementhub.

The management hub provides the customer with information relating totokens provisioned by the card network computing system 108 and/or theFI computing system 102 and related permissions, and allows the customerto manage the tokens. The management hub may also allow the customer tomonitor payment tokens issued for a given payment account. For example,the management hub may serve as an interface between the financialinstitution computing system 102 and the customer, wherein the customercan selectively allow and disallow transactions involving specificpayment card accounts with individual merchants, service providers, anddigital wallet services. In some arrangements, allowing and disallowingtransactions can be performed by activating and deactivating individualpayment tokens. Further, PANs may be activated or deactivated at themanagement hub to selectively enable and disable all transactionsinvolving a particular payment card account. In addition, in somearrangements, the management hub can provide the customer with an alertthat a payment token has been reprovisioned when a given payment tokenis compromised (e.g., in the event of a security breach at acorresponding merchant computing system 106, or a new PAN where aphysical credit card is lost).

For example, after a customer opens a new payment card account, thecustomer may subsequently lose the payment card associated with the cardaccount. However, the customer may be unsure whether the payment cardhas simply been temporarily misplaced, or whether the payment card hasbeen permanently lost. The customer may be provided with the ability toaccess the token management hub to temporarily deactivate the paymentcard for use with all merchants. Subsequently, the customer may locatethe payment card, and utilize the token management circuit to reactivatethe payment card. Alternatively, the customer may decide that thepayment card is permanently lost, and the token management circuit 206may interact with the card network computing system 108 to deactivatethe payment card and cause a new payment card to be issued. Once the newpayment card is created, the card network computing system 108 mayoperate to generate new payment tokens to replace the payment tokensassociated with the old payment card, and circulate the new paymenttokens to the respective merchants associated with the old paymenttokens.

As another example, the management hub may also allow the customer tomonitor payment tokens issued for a given payment account. For example,the management hub can provide a list of all merchants having a paymenttoken corresponding to a given payment card account. As such, thecustomer may be able to see whether any new or unusual payment tokenshave been provided without the permission of the customer (e.g., where afraudster in possession of the payment card attempts to transact with anew merchant). A new or unusual payment token appearing in themanagement hub circuit 212 may indicate that the payment card has beencompromised. For example, a fraudster may obtain a user's credit cardinformation, and use that credit card information in an onlinetransaction, thereby triggering the creation of a fraudulent paymenttoken at the online merchant. The customer may subsequently realize thatthe payment card has been compromised and may have the payment carddeactivated. However, the customer may also recognize the existence ofthe unusual/fraudulently-created payment token at the unknown merchantprior to the deactivation. The customer may then deactivate thatspecific payment token for that merchant, thereby causing the financialinstitution computing system 102 to deny any future transactions for thepayment card involving that merchant using the fraudulently-createdpayment token.

Additionally, the customer may choose to allow or disallow futuretransactions with a given merchant by updating permissions associatedwith a corresponding payment token. For example, a customer may visit amerchant once (e.g., while on vacation, while purchasing a gift for arelative, etc.). Such a merchant may be a merchant that the customer isunlikely to visit again. Hence, the customer may decide to deactivatethe payment token for that merchant, since the customer is unlikely tovisit that merchant again. As another example, the customer may havepurchased an item from a service that provides automatic renewals, suchthat the customer is charged on a periodic basis (e.g., the customer ischarged a $24.99 monthly service fee unless the customer takes steps toprevent the fee). In such a situation, the customer may deactivate thepayment token for that merchant to prevent such unwanted recurring feesfrom being charged in the future.

As another example, the management hub may permit the customer to sorttokens according to various parameters, such as by merchant category,most recent transaction date, transaction amount and so on. For example,the customer may be provided with the ability to sort merchant-specificpayment tokens by merchant classification code. In this manner, thecustomer may identify payment tokens associated with merchants that donot fit into the categories of merchants from which the user normallypurchases goods/services, which may suggest that those tokens werefraudulently created. On this basis, the user may decide to deactivatesuch tokens or the entire payment card. Likewise, the customer may sortpayment tokens by most recent transaction date and decide, e.g., todeactivate any payment token that has not been used in the past year.

As another example, the management hub can be used to provideinformation to customers about token activity. For example, if there isa data breach at a particular merchant, the card network computingsystem 108 may deactivate the payment token for that merchant andreprovision a new payment token for use with that merchant. Themanagement hub can provide the customer with an alert that a paymenttoken has been reprovisioned responsive to the data breach.

The data exchange circuit 208 of the FI computing system 102 isconfigured to exchange data among the FI customer database 202, thetoken database 204, the merchant computing system 106, and the customerdevice 104. In one aspect, the data exchange circuit 208 may beconfigured to exchange tokens and permissions with the token database204 and external computing systems (e.g., the merchant computing system106 and the customer device 104). For example, the data exchange circuit208 may provide a new token received from the card network computingsystem 108 to a customer device 104.

The customer device 104 includes customer network interface circuit 212and customer I/O devices 214. The customer network interface circuit 212is configured to allow the customer device 104 to exchange data over thenetwork 110. The customer I/O 214 includes hardware and associatedlogics configured to enable a customer to exchange information with thecustomer device 104. An input aspect of the customer I/O 214 allows thecustomer to provide information to the customer device 104, and caninclude, for example, a mechanical keyboard, a touchscreen, amicrophone, a camera, a fingerprint scanner, a user input deviceengageable to the customer device 104 (e.g., via a USB, mini USB, ormicro USB port, etc.), and so on. In turn, an output aspect of thecustomer I/O 214 allows the customer to receive information from thecustomer device 104, and can include, for example, a digital display, aspeaker, LEDs, and so on.

In some situations, the customer device 104 may receive and displayscreens including account information, transaction instructions, and soon. In one embodiment, a screen may be used to request a username andpassword information from the user, to prompt the user to provideinformation regarding the amount of a payment and which merchant orindividual (e.g., name, address, phone number or e-mail, a selection ofa recipient by the user from his/her memory or from the customer device104, etc.) is to receive the payment. Such screens are presented to theuser via the display device portion of the customer I/O 214. An inputdevice portion of the customer I/O 214 may be used to permit the user toinitiate account access and to facilitate receiving requestedinformation from the user.

In some situations, the customer device 104 may be a mobile device, suchas a cellular phone, smart phone, mobile handheld wireless e-maildevice, wearable device, portable gaming device, or other suitabledevice. In some embodiments, the mobile device may include a mobilewallet client application 216. The mobile wallet client application 216or mobile wallet circuit may include program logic executable by mobiledevice 104 to implement at least some of the functions described herein.In order to make the mobile wallet circuit 216, the FI computing system102 may provide a software application and make the software applicationavailable to be placed on the mobile device 104. For example, the FIcomputing system 102 may make the software application available to bedownloaded (e.g., via the online banking website of the mobile walletbank, via an app store, or in another manner). Responsive to a userselection of an appropriate link, the mobile wallet application may betransmitted to the mobile device and may cause itself to be installed onthe mobile device 104. Installation of the software application createsthe mobile wallet circuit on the mobile device 104. Specifically, afterinstallation, the thus-modified mobile device 104 includes the mobilewallet circuit (embodied as a processor and instructions stored innon-transitory memory that are executed by the processor).

In some situations, payment is made using a payment card 218. Thepayment card 218 is a physical payment card associated with a paymentcard account (e.g., a credit card account, a checking account, a prepaidaccount, etc.) for a given customer, and is capable of exchanginginformation stored in memory in the payment card 218. The payment card218 can also include visible information on the face of the card.

The payment card 218 includes a chip 219, a magstripe 220, and a PANindicator field 221. The PAN indicator field 221 conveys an accountnumber corresponding to a customer payment card account, and may beprinted or embossed on the physical payment card 218 (e.g., along with acustomer name, expiration date, security codes, etc.). The magstripe 220is a magnetically-responsive strip disposed on the face of the paymentcard 218. The magstripe 220 is configured to store a limited amount ofinformation (e.g., a payment card account number, a customer name,expiration date, etc.), e.g., in Track 1/Track 2 format. The chip 219 isa defining feature of the “smart” aspect of the payment card 218. Thechip 219 is a small circuitry system configured to exchange data viaelectrical contacts, RFID communication, NFC communication, or inanother manner. The chip 219 can be configured to be able to selectivelytransmit various types of information, including payment cardinformation (e.g., account numbers, issuing entities, and so on),identifying customer information (e.g., customer name, billing address,phone number, and so on).

In some arrangements, in addition to the PAN which is displayed in PANindicator field 221, the payment card 218 is further provided withchannel-specific payment tokens in the chip 219 and the magstripe 220.The PAN displayed in indicator field 221, the channel-specific tokenstored in the chip 219, and the channel-specific token stored in themagstripe 220 may each be different numbers. Hence, rather than beingprogrammed with the PAN, the chip 219 and the magstripe 220 areprogrammed with channel-specific payment tokens which are each differentthan the PAN. Accordingly, if a transaction involves the customerentering payment card information into an online interface (e.g., acheckout section of an online merchant), then the transaction iscompleted using the PAN of the payment card as presented in indicatorfield 221. Specifically, the merchant may transmit the PAN to the cardnetwork computing system 108 via the payment network, and the cardnetwork computing system 108 may return a payment token to the merchantcomputing system 106 to store in database 222 for future card-on filetransactions. Likewise, if a transaction involves the customer swipingthe payment card at a point of sale, then the transaction is completedusing the payment token stored in the magstripe 220. Likewise, if atransaction involves the customer inserting the payment card into a chipreader at a point of sale, then the transaction is completed using thepayment token stored in the chip 219. As such, the FI computing system102 may be able to distinguish customer transactions completed via thePAN displayed on the front of the card (e.g., where a payment cardaccount number is provided to an online merchant), the magstripe 220(e.g., at a magstripe reader at a merchant point of sale), or the use ofthe chip 219 (e.g., at a chip reader at a merchant point of sale).

In some arrangements, the chip 219 stores customer information inaddition to payment card account information. For example, customeridentification information may be stored at the chip 219 (e.g., a nameand address of the customer, driver's license number, a customerportrait image, etc.). In some embodiments, rather than storing theidentification information itself, a token is stored that may beexchanged for the identification information. As such, the chip 219 maybe used by a merchant computing device 106 for personal identificationof the customer (e.g., to pick up airline tickets at an automatedkiosk). For example, the merchant computing system 106 may read theidentification information directly from the chip 219, or may submit thetoken to the FI computing system 102, depending on where theidentification information is stored.

In some embodiments, e.g., in situations where a token is stored ratherthan the identification information itself, the customer may accesstoken management circuit 206 in order to update the informationassociated with the token. Hence, each time a transaction occurs, themerchant computing system 106 may submit the token to the FI computingsystem 102 in order to verify that the address information stored by themerchant computing system 106 for the customer is the mostrecent/up-to-date information.

In some embodiments, the information that is stored (either locally onthe chip 219 or remotely accessible via a token) may include informationfor the merchant to establish a loyalty account. Hence, rather than askthe customer to fill out a form to provide information to establish aloyalty account, the merchant computing system 106 may instead read theinformation used to create the loyalty account from the payment card218.

In some embodiments, merchant or financial institution loyalty programsmay be implemented with loyalty account numbers that are specific toeach customer, and the loyalty account numbers (or tokens representingthe loyalty account numbers) may be stored on the chip 219. As such, theloyalty account numbers may be retrieved from a chip reader (e.g., atevery transaction involving the payment card 218), e.g., therebyavoiding the need for the customer to separately present a loyalty cardor a phone number associated with the loyalty account at the point ofsale. In other embodiments, each customer may be assigned a unique IDthat is universal across multiple loyalty programs. Hence, the merchantcomputing system 106 may be configured to identify the customer based onthe unique ID, and then provide loyalty program rewards to the customerusing the unique ID as the basis for identifying the customer.

As another example, in some embodiments, the chip 219 may beread/writable by the merchant computing system 106 (e.g., the merchantpoint-of sale-device can read from and write to the chip 219). In suchembodiments, rewards balance information may be stored directly on thepayment card 218, and used as currency in future transactions with themerchant.

The merchant computing system 106 includes a merchant customer database222 and a merchant network interface circuit 224. The merchant networkinterface circuit 224 is configured to allow the merchant computingsystem 106 to exchange data over the network 110. The merchant customerdatabase 222 is a local or remote data storage system, and may beconfigured to store customer information relevant for completingpurchase transactions. For example, the merchant customer database 222can include customer names, shipping addresses, billing addresses,payment card information (e.g., tokens), phone numbers, and so on.

The card network computing system 108 comprises a token managementcircuit 226 and a token database 228. The token management circuit 226is configured to generate and manage tokens associated with paymentcards. The token database 228 maintains the mapping of paymenttokens-to-PANs, such that payment tokens may be detokenized duringprocessing of payment transactions to determine actual account numbers.The card network computing system 108 also includes a network interfacecircuit 230 which is configured to allow the card network computingsystem 108 to exchange data over the network 110.

Referring now to FIGS. 3A-3D, as previously indicated, the customer mayuse the customer device 104 to manage payment tokens via the tokenmanagement circuit 206. For example, the customer may enable and disablefinancial transactions with individual merchants (e.g., merchantsassociated with the merchant computing system 106) against one or morepayment cards. Further, in some arrangements, the customer may also beable to selectively enable and disable exchanges of customer data (e.g.,customer names, shipping addresses, contact information, and the like),by type of customer data and/or by individual merchants. The customerdevice 104 may also be used to secure a payment card account in theevent that the payment card account is compromised at a specificmerchant, or the new payment card account itself is compromised. Such anarrangement is shown in greater detail in FIGS. 3A-3D.

Referring first in detail to FIG. 3A, an example graphical userinterface (“GUI”) 300 is provided on a user device 104 (e.g., via thecustomer I/O 214). The GUI 300 is generated by the token managementcircuit 206. In one arrangement, the GUI 300 presents a customer with awelcome page 310 after the user provides authorizing credentials (e.g.,a username and password, an entry of biometric data, or the like via thecustomer I/O 214). The welcome page 310 includes a plurality of menubuttons 304, each of the menu buttons 304 being labeled with acorresponding action that the token management circuit 206 may perform(e.g., see account information, send payments, etc.). Included among themenu buttons 304 is a labeled button corresponding to the managementhub.

Referring now to FIG. 3B, in response to a user selection of themanagement hub option within the menu buttons 304 provided in FIG. 3A,the GUI 300 has refreshed to show a management hub page 320. Informationprovided on the management hub page 320 includes information from thetoken database 204, which may be accessed and transmitted by the dataexchange circuit 208 over the network 110 via the FI network interfacecircuit 210. In one arrangement, the management hub page 320 isorganized into a first payment card account section 321 and a secondpayment card account section 322. Each payment card account sectioncorresponds to a payment card account provided by the financialinstitution associated with the financial institution computing system102. As shown in FIG. 3B, two payment card account sections areprovided, indicating that the user is associated with two payment cardaccounts.

A sample window 323 (i.e., highlighted for illustrative purposes) of aportion of the first payment card account section 321 is provided toindicate various types of information provided in a given payment cardaccount section. The sample window 323 includes a payment card accountidentifier 324 (e.g., identifying a credit card with a PAN ending in“−0123”). In one arrangement, a user can select a PAN reprovisioningbutton 325, thereby causing the management circuit 206 to initiateissuance of a new payment card with a new PAN to the customer. (As willbe appreciated, although certain terminology is used in the userinterface example of FIGS. 3A-3D, other terminology may also be used inpractice.) The token management circuit 206 may then cooperate with thecard network computing system 108 to generate a new PAN for a newpayment card, generate new payment tokens for the new payment card,distribute those payment tokens to merchants and other channels, andupdate the token databases 204 and 228.

The sample window 323 also includes a merchant identifier 326. Themerchant identifier 326 specifies a merchant to which a payment tokenhas been assigned. Using a pair of enabling toggles 327, a user mayadjust the payment token permissions stored at the token database 204for each merchant associated with a given payment card account. Uponchoosing to disable a given payment token via the corresponding enablingtoggle 327, the token management circuit 206 disallows any additionaltransactions for the merchant corresponding to the merchant identifier326 involving the payment card account associated with the payment cardaccount identifier 324. Disabling the payment token may involve updatingcorresponding data in the token database 204. In turn, choosing toenable the payment token will cause the token management circuit 206 toallow such transactions.

In addition, if a user no longer wishes to transact with a givenmerchant, or if a payment token was created accidentally orfraudulently, the user may select a payment token deletion button 329 toremove a corresponding payment token from the token database 204altogether.

Referring now to FIG. 3C, in some arrangements, the GUI 300 can providean account page 330 specific to a given payment card account. Theaccount page 330 can include a single payment card account section 331having information and functionalities similar to that offered bypayment card account sections (e.g., the first payment card accountsection 321 and the second payment card account section 322) in theaccount security hub page 320 (e.g., token management functions).

In some arrangements, the account page 330 includes a representativecard image 332. The card image 332 may represent the appearance of aphysical payment card corresponding to a given payment card account. Forexample, where a customer was provided a physical payment card bearing acustomized image on a front side of the card (e.g., a favorite picturesuch as a picture of a family member(s), a pet, a landscape, etc.), thecard image 332 may include the customized image as well. The card image332 may be stored in the FI customer database 202, and provided to thecustomer device 104 over the network 110 after the customer hub circuit212 is set up (e.g., via the data exchange circuit 208 in cooperationwith the FI network interface circuit 210).

In some embodiments, the card image (e.g., as presented via mobilewallet circuit 216) can change at a point of sale to reflectcharacteristics of the point of sale transaction. For example, if thecustomer is at a pet store, the card image may change to show a pictureof the customer's pet. Conversely, if the customer is at a floral shop,the card image may change to show a picture of the customer'sspouse/significant other. The mobile wallet circuit 216 may beconfigured to determine point of sale characteristics via, for example,a GPS functionality at the customer device 104, or access to a localwireless network associated with a given merchant.

The card image 332 may also include a notification 333. In somearrangements, the notification 333 is incorporated into the card image332 (e.g., as a symbol as shown, as an indicative color of acorresponding color code, or the like). The notification 333 can providenotice to a user of some status or condition relating to the paymentcard account corresponding to the account page 330. For example,information in the FI customer database 202 may show that a card paymentis coming due, that a certain amount of a balance or credit limit orbudget has been expended, or some other aspect may need attention. Suchinformation may be reflected in the notification 333 as a color (e.g.,red for approaching or exceeding spending limits), a symbol (e.g., anexclamation mark for an upcoming due date), or the like. In somearrangements, the notification 333 is a selectable button, wherein theGUI 300 refreshes to provide the user with an appropriate screen (e.g.,a payments screen, a transaction history screen, etc.).

Referring now to FIG. 3D, the GUI 300 may provide a customer informationpage 340 (e.g., responsive to a user selection of a menu button 304 onthe welcome page 310 corresponding to customer information). In somearrangements, the customer information page 340 includes an informationlisting 341 corresponding to personal and identifying information intextual form. For example, the information listing 341 may include aname, address, phone number, and email address. Other similar types ofinformation may be included in the information listing 341 as well.Further, in some arrangements, the customer information page 340 mayreflect successful collection of customer biometric data. For example, astored fingerprint 342 and iris scan 343 specific to the user may beincluded or acknowledged in the customer information page 340. Suchinformation may then, for example, also be propagated to other userdevices, such that the user can use the same biometrics to access otherdevices.

In some arrangements, a user may be able to select an update button 344in order to update or revise the information in the customer informationpage 340. Information in the customer information page 340 may be storedin the FI customer database 202 at the financial institution computingsystem 102, and exchanged with the customer device 104 and the merchantcomputing system 106 via the data exchange circuit 208 (e.g., over thenetwork 110 by the FI network interface 210). Further, some or all ofthe information in the customer information page 340 may be stored inthe chip 219 of the issued payment card 218. Upon selecting the updatebutton 344, updated or revised information can be received by thecustomer device 104 (e.g., via an appropriate aspect of the customer I/O214), and then transmitted to the data exchange circuit 208 over thenetwork 110. The data exchange circuit 208 may store the updated orrevised information in the FI customer database 202 as well as circulateit to the merchant computing system 106. The data exchange circuit 208may also cause the chip 219 to be updated, for example during a dataexchange with the financial institution computing system 102 at a pointof sale or a brick and mortar banking location, or by issuing a newpayment card 218 with an updated chip 219.

As such, the GUI 300 can be configured to provide a way for the customerto update information at the FI customer database 202. For example,after a customer moves to a new residence, the customer may access thecustomer information page 340 on the customer device 104, select theupdate button 344, and enter an updated mailing address into thecustomer device 104. The customer device 104 subsequently transmits theupdated mailing address to the financial institution computing system102 over the network 110, where it is received by the data exchangecircuit 208. The data exchange circuit 208 may store the updated mailingaddress in the FI customer database 202.

In some arrangements, the data exchange circuit 208 may also provide theupdated mailing address to one or more merchant computing systems 106.In one such arrangement, the data exchange circuit 208 accesses thetoken database 204 to identify merchants corresponding tocustomer-enabled payment tokens (e.g., via the enabling toggles 327).Upon identifying such merchants, the data exchange circuit 208 maytransmit the updated mailing address to their respective merchantcomputing systems 106 over the network 110 via the FI network interfacecircuit 210.

In another such arrangement, the data exchange circuit 208 accesses theFI customer database 202 to identify merchants corresponding to previouspayment transactions. For example, the data exchange circuit 208 may beconfigured to search through transaction histories of a customer in theFI customer database 202 to identify such merchants. In somearrangements, the data exchange circuit 208 may be configured to limitthe search to transactions within a specific timeframe (e.g., within thepast year, within the past six months, etc.). Further, the data exchangecircuit 208 may be configured to also confirm that any merchantsidentified in the transaction histories correspond to customer-enabledtokens in the manner discussed above.

The data exchange circuit 208 may transmit the updated mailing addressto a merchant computing system 106 upon receiving and processing theupdated mailing address on a rolling basis or in batches. Alternatively,the data exchange circuit 208 may provide the updated mailing address toa merchant computing system 106 upon receiving a transaction requestfrom the merchant computing system 106. In effect, the next time thecustomer orders from one of the customer-enabled merchants, the customermay not need to provide the updated mailing address to complete thetransaction. Other types of customer information (e.g., phone numbers,email addresses, identification information, loyalty programinformation, etc.) may be updated in a similar manner.

In addition, in some arrangements, token management circuit 206 isconfigured to provide some or all aspects of the GUI 300 on multiplechannels, enabling the GUI 300 to be viewed and manipulated by multipleusers. For example, a financial institution I/O (e.g., similar to thecustomer I/O 214, but disposed at a financial institution facility) maybe configured to allow a customer service representative to interfacewith the financial institution computing system 102. The tokenmanagement circuit 206 may be configured to provide the GUI 300 at boththe financial institution I/O and the customer I/O 214 simultaneously(e.g., over the network 110 via the FI network interface circuit 210).As such, the customer service representative may be able to guide acustomer through GUI 300 in real time. In addition, both the customerservice representative and the customer may perform any of theoperations discussed above while simultaneously viewing the same pagesof the GUI 300.

FIG. 4 illustrates a process 400 that may be implemented by the systemof FIGS. 1-2. By way of example, FIG. 4 shows a mobile wallettransaction. As will be appreciated, the system 100 supports other typesof transactions as well, such as card on file transactions, card presenttransactions, and so on.

When a user wishes to make a payment at a merchant, for example, theuser may access the mobile wallet client application 216 by entering aPIN or other login credentials and then selecting a “pay now” or similarbutton. For example, the user may be located at a merchant location andmay wish to pay for a good or service. As another example, the user maybe located away from the merchant location or be engaged in an onlinetransaction.

At step 401, the mobile device 104 may transmit a payment token tomerchant computer system 140 (e.g., using a QR code, NFC, wireless,Bluetooth, low energy Bluetooth, RFID, hypersonic, Wi-Fi, cellular 3G,4G, GSM, LiFi, or other method). In some embodiments, the payment tokenis provisioned to the mobile wallet circuit 216 in advance and is reusedfor many mobile wallet transactions. In other embodiments, the paymenttoken is dynamically provisioned to the mobile wallet circuit 216. Forexample, when the user selects the “pay now” button, the mobile walletcircuit 216 may send a request to a mobile wallet computer system (notshown) which, in response, provisions a one-time payment token to themobile wallet circuit 216.

At step 403, after receiving the payment token, the merchant computersystem 104 sends the transaction to an acquirer processor computersystem 112 for processing. Next, at step 405, the acquirer processorcomputer system 112 sends the payment token to the card network computersystem 108 for processing a payment. The card network computer system108 detokenizes the payment token, thereby resulting in the actual cardnumber (PAN). At step 407, the card network computer system 108 sendsthe PAN to the FI computer system 102. The FI computer 102 thenprocesses the transaction, for example, by approving the transactionbased on the account status of the user (e.g., by confirming that theuser has not exceed the credit limit of their credit card). The FIcomputer system 102 may then send an approval to the merchant computingsystem 106 via the card network computer system 108, the acquirerprocessor 112 (steps 409-413), and the payment to the merchant is made.Upon receiving the approval message, the point of sale system 140 maygenerate a receipt for the user. In some embodiments, the receipt may besent to the mobile device 110 electronically. In other embodiments, thereceipt may be printed physically at the point of sale location.

In the preceding example, it is assumed that the user pays the merchantwith a pre-existing payment card (i.e., from a payment card account thatwas in existence prior to the user visiting the merchant). In othersituations, the user may pay the merchant with a new payment card. Forexample, the user may be at a merchant that has an online mechanism forcreating a credit application for a merchant-specific payment card(e.g., a store-branded credit card). For example, the customer may usethe mobile device 104 to download and install a merchant softwareapplication. Using the software application, at the point of sale, thecustomer may apply for and open a new payment card account (e.g., a newcredit card account). The financial institution associated with themerchant-specific payment card may then electronically activate the newpayment card and provision the new payment card to the customer (e.g.,to a mobile wallet application executed by the customer device 104). Thecustomer may then use the new payment card at the point of sale. At thesame time, the physical payment card may be mailed to the customer, andthe customer may activate the physical payment card upon receipt in themail.

The scope of this disclosure should be determined by the claims, theirlegal equivalents and the fact that it fully encompasses otherembodiments which may become apparent to those skilled in the art. Allstructural, electrical and functional equivalents to the elements of thebelow-described disclosure that are known to those of ordinary skill inthe art are expressly incorporated herein by reference and are intendedto be encompassed by the present claims. A reference to an element inthe singular is not intended to mean one and only one, unless explicitlyso stated, but rather it should be construed to mean at least one. Noclaim element herein is to be construed under the provisions of 35U.S.C. § 112, sixth paragraph, unless the element is expressly recitedusing the phrase “means for.” Furthermore, no element, component ormethod step in the present disclosure is intended to be dedicated to thepublic, regardless of whether the element, component or method step isexplicitly recited in the claims.

The embodiments in the present disclosure have been described withreference to drawings. The drawings illustrate certain details ofspecific embodiments that implement the systems, methods and programs ofthe present disclosure. However, describing the embodiments withdrawings should not be construed as imposing any limitations that may bepresent in the drawings. The present disclosure contemplates methods,systems and program products on any machine-readable media foraccomplishing its operations. The embodiments of the present disclosuremay be implemented using an existing computer processor, or by a specialpurpose computer processor incorporated for this or another purpose orby a hardwired system.

As used herein, “circuit” may include program logic executable byhardware disposed at a computing system to implement at least some ofthe functions described herein. Embodiments within the scope of thepresent invention include program products comprising non-transitorymachine-readable media for carrying or having machine-executableinstructions or data structures stored thereon. Such machine-readablemedia may be any available media that may be accessed by a generalpurpose or special purpose computer or other machine with a processor.By way of example, such machine-readable media may comprise RAM, ROM,EPROM, EEPROM, CD-ROM or other optical disk storage, magnetic diskstorage or other magnetic storage devices, or any other medium which maybe used to carry or store desired program code in the form ofmachine-executable instructions or data structures and which may beaccessed by a general purpose or special purpose computer or othermachine with a processor. Thus, any such a connection is properly termeda machine-readable medium. Combinations of the above are also includedwithin the scope of machine-readable media. Machine-executableinstructions comprise, for example, instructions and data which cause ageneral purpose computer, special purpose computer, or special purposeprocessing machines to perform a certain function or group of functions.

Embodiments in the present disclosure have been described in the generalcontext of method steps which may be implemented in one embodiment by aprogram product including machine-executable instructions, such asprogram code, for example, in the form of program modules executed bymachines in networked environments. Generally, program modules includeroutines, programs, objects, components, data structures, etc. thatperform particular tasks or implement particular abstract data types.Machine-executable instructions, associated data structures, and programmodules represent examples of program code for executing steps of themethods disclosed herein. The particular sequence of such executableinstructions or associated data structures represent examples ofcorresponding acts for implementing the functions described in suchsteps.

As previously indicated, embodiments in the present disclosure may bepracticed in a networked environment using logical connections to one ormore remote computers having processors. Those skilled in the art willappreciate that such network computing environments may encompass manytypes of computers, including personal computers, hand-held devices,multi-processor systems, microprocessor-based or programmable consumerelectronics, network PCs, minicomputers, mainframe computers, and so on.Embodiments in the disclosure may also be practiced in distributedcomputing environments where tasks are performed by local and remoteprocessing devices that are linked (either by hardwired links, wirelesslinks, or by a combination of hardwired or wireless links) through acommunications network. In a distributed computing environment, programmodules may be located in both local and remote memory storage devices.

An exemplary system for implementing the overall system or portions ofthe disclosure might include one or more computers including aprocessor, a system memory or database, and a system bus that couplesvarious system components including the system memory to the processor.The database or system memory may include read only memory (ROM) andrandom access memory (RAM). The database may also include a magnetichard disk drive for reading from and writing to a magnetic hard disk, amagnetic disk drive for reading from or writing to a removable magneticdisk, and an optical disk drive for reading from or writing to aremovable optical disk such as a CD ROM or other optical media. Thedrives and their associated machine-readable media provide nonvolatilestorage of machine-executable instructions, data structures, programmodules and other data for the computer. User interfaces, as describedherein, may include a computer with a monitor, a keyboard, a keypad, amouse, a joystick or other input devices performing a similar function.

It should be noted that although the diagrams herein may show a specificorder and composition of method steps, it is understood that the orderof these steps may differ from what is depicted. For example, two ormore steps may be performed concurrently or with partial concurrence.Also, some method steps that are performed as discrete steps may becombined, steps being performed as a combined step may be separated intodiscrete steps, the sequence of certain processes may be reversed orotherwise varied, and the nature or number of discrete processes may bealtered or varied. The order or sequence of any element or apparatus maybe varied or substituted according to alternative embodiments.Accordingly, all such modifications are intended to be included withinthe scope of the present disclosure. Such variations will depend on thesoftware and hardware systems chosen and on designer choice. It isunderstood that all such variations are within the scope of thedisclosure. Likewise, software and web implementations of the presentinvention could be accomplished with standard programming techniqueswith rule based logic and other logic to accomplish the various databasesearching steps, correlation steps, comparison steps and decision steps.

The foregoing description of embodiments has been presented for purposesof illustration and description. It is not intended to be exhaustive orto limit the subject matter to the precise form disclosed, andmodifications and variations are possible in light of the aboveteachings or may be acquired from practice of the subject matterdisclosed herein. The embodiments were chosen and described in order toexplain the principals of the disclosed subject matter and its practicalapplication to enable one skilled in the art to utilize the disclosedsubject matter in various embodiments and with various modifications asare suited to the particular use contemplated. Other substitutions,modifications, changes and omissions may be made in the design,operating conditions and arrangement of the embodiments withoutdeparting from the scope of the presently disclosed subject matter.

Throughout the specification, numerous advantages of the exemplaryembodiments have been identified. It will be understood, of course, thatit is possible to employ the teachings herein without necessarilyachieving the same advantages. Additionally, although many features havebeen described in the context of a particular data processor, it will beappreciated that such features could also be implemented in the contextof other hardware configurations.

While the exemplary embodiments illustrated in the figures and describedabove are presently preferred, it should be understood that theseembodiments are offered by way of example only. Other embodiments mayinclude, for example, structures with different data mapping ordifferent data. The disclosed subject matter is not limited to aparticular embodiment, but extends to various modifications,combinations, and permutations that nevertheless fall within the scopeand spirit of the appended claims.

What is claimed is:
 1. A computing system for managing customer tokens,the system comprising: a token database retrievably storing a pluralityof tokens and token information associated with each of the plurality oftokens; a network interface circuit enabling the computing system toexchange information over a network; and a token management circuitconnected to a graphical user interface on a customer device, the systemperforming the steps of: displaying, on the graphical user interface, alist of merchants and one or more tokens associated with each of saidmerchants, wherein each token indicates whether the token is enabled ordisabled; receiving, by the graphical user interface, first instructionsto either enable or disable a first token of the one or more tokensassociated with said corresponding merchant; receiving, by the graphicaluser interface, second instructions to delete a second token of the oneor more tokens associated with said corresponding merchant; and updatingthe token database according to the first and second instructions; and acustomer database retrievably storing customer account information,wherein the system further performs the steps of: displaying, on thegraphical user interface, customer account information comprisingpersonal information of a customer associated with a payment cardaccount corresponding to the one or more tokens associated with saidcorresponding merchant; displaying, on the graphical user interface, arepresentation of a payment card image; receiving, by the graphical userinterface, third instructions to change the customer accountinformation; modifying, on the graphical user interface, the paymentcard image in response to receiving the third instructions; receiving,by the graphical user interface, information associated with a point ofsale from a remote device, and modifying, by the graphical userinterface, the payment card image to reflect characteristics associatedwith the point of sale.
 2. The computing system of claim 1, wherein thefirst instructions are in response to selection of a first button of thegraphical user interface, and the second instructions are in response toselection of a second button of the graphical user interface.
 3. Thecomputing system of claim 1, wherein the system further performs thestep of receiving, by the graphical user interface, third instructionsto re-provision a primary account number (PAN) of a third token of theone or more tokens associated with said corresponding merchant.
 4. Thecomputing system of claim 3, wherein updating the token databasecomprises reissuing a new payment card and a new PAN in response toreceiving the third instructions.
 5. The computing system of claim 4,wherein updating the token database further comprises generating areplacement payment token for the new payment card and distributing thereplacement token to one or more merchant systems in response toreceiving the third instructions.
 6. The computing system of claim 1,wherein the list of merchants is a first list of merchants, and whereinthe system further performs the step of: displaying, on the graphicaluser interface, a second list of merchants and one or more tokensassociated with each of said merchants in the second list of merchants,wherein each token indicates whether the token is enabled or disabledand presents a selectable button for deleting said token; wherein thefirst list of merchants is associated with a first payment card accountand the second list of merchants is associated with a second paymentcard account that is different from the first payment card account. 7.The computing system of claim 1, wherein the system further performs thesteps of displaying, on the graphical user interface, one or moreeditable fields configured to receive updates to the customer accountinformation, and transmitting the updates to the customer accountinformation to one or more remote merchant computing systems.
 8. Amethod of enabling customer information management, the methodcomprising: storing, at a token database, information regarding aplurality of tokens; displaying, on a graphical user interface, a listof merchants and one or more tokens associated with each of saidmerchants, wherein each token indicates whether the token is enabled ordisabled; receiving, by the graphical user interface, first instructionsto either enable or disable a first token of the one or more tokensassociated with said corresponding merchant; receiving, by the graphicaluser interface, second instructions to delete a second token of the oneor more tokens associated with said corresponding merchant; updating thetoken database according to the first and second instructions;displaying, on the graphical user interface, customer accountinformation that includes personal information of a customer associatedwith a payment card account corresponding to the one or more tokensassociated with said corresponding merchant; displaying, on thegraphical user interface, a representation of a payment card image;receiving, by the graphical user interface, third instructions to changethe customer account information; modifying, on the graphical userinterface, the payment card image in response to receiving the thirdinstructions; receiving, by the graphical user interface, informationassociated with a point of sale from a remote device; and modifying, bythe graphical user interface, the payment card image to reflectcharacteristics associated with the point of sale.
 9. The method ofclaim 8, further comprising receiving, by the graphical user interface,third instructions to re-provision a primary account number (PAN) of athird token of the one or more tokens associated with said correspondingmerchant.
 10. The method of claim 9, wherein updating the token databasefurther comprises generating replacement payment tokens for the newpayment card and distributing the replacement tokens to one or moremerchant systems in response to receiving the third instructions. 11.The method of claim 8, further comprising displaying, by the graphicaluser interface, one or more editable fields configured to receiveupdates to the customer account information, and transmitting theupdates to the customer account information from the data exchangecircuit to remote merchant computing systems.
 12. A non-transitorycomputer readable media having computer-executable instructions embodiedtherein that, when executed by a processor of a computing system, causethe computing system to perform the steps of: storing, at a tokendatabase, information regarding a plurality of tokens; displaying, on agraphical user interface, a list of merchants and one or more tokensassociated with each of said merchants, wherein each token indicateswhether the token is enabled or disabled; receiving, by the graphicaluser interface, first instructions to either enable or disable a firsttoken of the one or more tokens associated with said correspondingmerchant; receiving, by the graphical user interface, secondinstructions to delete a second token of the one or more tokensassociated with said corresponding merchant; updating the token databaseaccording to the first and second instructions; displaying, on thegraphical user interface, customer account information that includespersonal information of a customer associated with a payment cardaccount corresponding to the one or more tokens associated with saidcorresponding merchant; displaying, on the graphical user interface, arepresentation of a payment card image; receiving, by the graphical userinterface, third instructions to change the customer accountinformation; modifying, on the graphical user interface, the paymentcard image in response to receiving the third instructions; receiving,by the graphical user interface, information associated with a point ofsale from a remote device; and modifying, by the graphical userinterface, the payment card image to reflect characteristics associatedwith the point of sale.
 13. The non-transitory computer-readable mediaof claim 12, wherein the instructions further cause the computing systemto perform the step of receiving, by the graphical user interface, thirdinstructions to re-provision a primary account number (PAN) of a thirdtoken of the one or more tokens associated with said correspondingmerchant, and wherein updating the token database comprises: reissuing anew payment card and a new PAN in response to receiving the thirdinstructions to re-provision the PAN of the third token; generating areplacement payment token for the new payment card; and distributing thereplacement payment token to one or more merchant systems in response toreceiving the third instructions.
 14. The non-transitorycomputer-readable media of claim 12, wherein the instructions furthercause the computing system to perform the steps of storing customeraccount information at a customer database, and displaying, on thegraphical user interface, customer account information of a customerassociated with a payment card account corresponding to the one or moretokens associated with said corresponding merchant.